With the advent of 3G mobile telephony, new packet-based communication technologies have been developed for communicating multimedia content. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies support wireless multimedia telephony services involving packet-switched communication of data representing images, text, documents, animations, audio files, video clips, etc., in addition to traditional circuit-switched voice calls. Further, new sophisticated mobile terminals are also emerging on the market, equipped with functionalities to handle the new services, including high resolution colour displays and multiple codecs (coders/decoders) for the different formats. These terminals are also typically capable of different access technologies, depending on network configuration and cell characteristics.
Recently, a service network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to provide multimedia services for mobile clients in the packet domain. Generally, IMS is a platform for enabling services based on IP transport, more or less independent of the access technology used and basically not restricted to any limited set of specific services.
A specification for session setup has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261 et al), which is an application-layer signalling protocol for controlling (e.g. creating, modifying and terminating) sessions over a packet-switched logic. SIP is generally used by IMS networks for handling multimedia sessions. Also, extensions of the basic SIP protocol may be used, referred to as “Simple”, to handle some services.
FIG. 1 illustrates schematically a greatly simplified basic communication scenario for providing multimedia services by means of an IMS service network. It should be noted that the figure only shows a selection of network elements helpful to understand the background technology for the present invention. Briefly described, a calling mobile terminal A is connected to a first radio access network 100 and communicates with a called mobile terminal B connected to a second radio access network 102, in a communication session S involving one or more multimedia services. Alternatively, terminal A may communicate with a fixed terminal or computer, or with a content server delivering some multimedia content to the terminal, such as a piece of music, a film or a game. The terminals A, B may also communicate with servers in the IMS network providing information services, to be described below.
An IMS network 104 is shown connected to the first radio access network 100 and handles the multimedia session S with respect to terminal A. Thus, the IMS network 104 receives and processes any service requests from terminal A. Similarly, a corresponding IMS network 106 handles the session S on behalf of terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Alternatively, terminals A and B may of course be connected to the same access network and/or may be served by the same IMS network.
The illustrated session S is controlled, using SIP signalling, by various suitable session managing nodes, generally indicated by a block 108. Typically, the session managing node types include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function). Invoked multimedia services are enabled and executed by a plurality of application servers 110. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things, that the application servers 110 can fetch for executing services for clients. The various functions of the IMS network elements 108-112 are not necessary to describe here further to understand the present invention. Of course, the IMS network 104 further contains numerous other nodes and functions, which are not shown here for the sake of simplicity.
One example of services that can be employed by means of an IMS network is the so-called “Presence” services. In this type of services, “Presence” is basically a dynamic and variable state profile of a client, and the presence services basically involve the publishing of “presence data” of a client to make it available for other users and applications, which further can be used to control other services in turn. Presence data basically defines the state or situation of a client and his/her equipment in some predefined respect. Thus, the term “presence” is here given a very broad meaning, and the presence data may include, e.g., the following “client states”:                A client status, e.g. available, busy, in a meeting, on holiday, etc.        A terminal status, e.g. switched on/off, engaged, out of coverage, etc.        The geographic location of the client/terminal.        Terminal capabilities and selections, e.g. functionality for SMS, MMS, chatting, games, video, etc.        Other personal client information, e.g. interests, occupations, personal characteristics, moods, etc.        
This information, or any selected parts thereof, is stored in an application server in the IMS network, based on so-called “publications of events” received from the network or a client, whenever the client changes any of his/her presence data. A client may also subscribe for selected presence data of one or more other users, e.g. according to a list of users. Such presence subscriptions are typically also handled by an application server in the IMS network. The subscribing client can then receive notifications regarding current presence data, either automatically or upon request. In SIP, a message called “SIP PUBLISH” can be used by clients to provide dynamic data to an application server in the IMS network. Further, another SIP message called “SIP SUBSCRIBE” can be used by clients to subscribe for dynamic data of other clients, as handled by the application server.
In traditional telecommunication systems, communication channels are more or less fixed and static, with predictable bitrates and protocols. Using the new access technologies, however, the network environment becomes more dynamic and heterogeneous to users, with great variations of the available communication resources in wireless networks, as different types of connection can be used, even within a call session. As a result, bitrates and modulation and encoding schemes become highly variable. Yet, users moving around in and between networks expect to be able to access and utilize a variety of services regardless of such variations. It is therefore desirable to develop services that can be adapted, or “tailored”, to the current user situation and network environment.
Recently, a concept has been developed to provide refined information on objects to increase the usability of applications for invoked services, depending on the object's current situation. An “object” in this respect is typically a human user but may also be a physical device or apparatus, or an enterprise offering merchandise or services to customers. The term “object of interest” will be used in this description to represent any such object. This new concept is generally referred to as the distribution of “context” information, which may be implemented by using similar mechanisms as of the above-described presence services. It is therefore desirable to develop “context-aware” applications to achieve services optimally adapted to the prevailing circumstances.
This may be illustrated by a first example when a telecommunication service involving a navigation aid has been invoked by a mobile user. A context may then be defined in an IMS server for that user, being the object of interest in this case. The context may be maintained in the server e.g. for as long as the user is logged-on, or as long as he/she is a subscriber in the IMS network. An application used for this service may then investigate the current context of the user and provide a map to the user adapted to include or exclude certain features depending on, e.g., the user's preferences, current position and current type of communication connection, as being given by the context. In this case, the context information reflecting the user's situation can thus be used to create an optimal presentation format, i.e. the displayed map.
FIG. 2 illustrates a previously proposed server configuration for providing context information on an object of interest to a requesting entity, or “context consumer”. A context server 200 is shown, adapted to provide context information to any authorized user, device or application, generally illustrated here as a “requesting party” 202. It should be noted that the object of interest for which context information is maintained may be a person, device, apparatus, system, etc. Further, the requesting party 202 may likewise be a person, e.g. a presence subscriber as described above, or a device. The requesting party 202 may also be an application being used to enable a service, such as the navigation aid service described above.
The context server 200 includes a context manager 204, an advertiser 206 and an admission control function 208, to be described below. The context manager 204 continuously collects information on the object of interest, here schematically illustrated as a dashed box 210a, by receiving object data from various sources, indicated as sensors S 210. The sensors 210 are adapted to measure or register various “variables” or the like characterizing the current state, status or situation of the object 210a. For example, the sensors may be adapted to measure physical characteristics such as temperature, or to register some current object status such as any of the client states mentioned above for presence services. In another tangible example, the object of interest may be a power switch and a single sensor may then be adapted to simply register whether the switch is on or off.
Raw context data from the sensors 210 is received and stored in a context storage unit 212 in the context manager 204. The stored raw data may then be processed and refined in a context refiner 214 by applying predefined rules 216 on the raw data, in order to derive or calculate new refined context information from the raw data. The predefined rules 216 may include algorithms or the like that calculate certain parameters, draw conclusions or create compilations from the raw data. For example, in the case of the above-mentioned power switch, rules may be defined to derive various statistic parameters. One rule may calculate the total amount of time the switch has been on and off, respectively. Other rules may calculate the maximum, minimum and mean duration of periods it has remained on and off, respectively, and so forth.
The refined context can then be distributed correctly to any requesting party by means of a distributor 218. The requesting party 202 may first discover what context information can be obtained from the context server by checking advertisements or announcements provided by means of some “exposure” mechanism according to suitable information from the advertiser 206. For example, advertisements or announcements regarding available context information may be exposed, as indicated in the figure by a dashed line, by means of a separate server or the like. Then, the requesting party 202 may make a request for context information which is received at the admission control unit 208. This unit 208 is adapted to apply a policy on the context request to determine whether the requesting party 202 is authorised to receive context information of the object of interest. The policy has been defined basically by the context owner, e.g. a network operator. If so, the admission control unit 208 triggers the distributor 218 to provide the latest context information to the requesting party 202. The policy may also dictate that a particular requester is allowed to receive only some part of the available context information. It should be noted that the context request may be a request for a subscription to receive context information from the context server on a more or less continuous basis.
Typically, the context information pertains to an individual object, e.g. a person. However, an object may also belong to a group of objects, e.g. persons, having an aggregate profile shared by its members. A group membership per se may be regarded as a parameter in an individual context. For example, members of a family may each have an individual context while the family may have a common context with an aggregate profile shared by its members. Today, no mechanism is available for creating an aggregated context for a group of individuals or devices.
Using the above-described solution of FIG. 2, the rules creating the refined context information are predefined and fixed, and the refined context information can be provided to any authorised requesting party. In this way, the requesting party can only receive context according to its predefined form, which is sometimes a problem since it may not be exactly what the requesting party needs or desires. However, no flexible solution is available today for meeting the particular needs of a requesting party, being limited to the predefined context refinements only. The requesting party will also receive all the available context information, sometimes limited by the policy, even though parts of it may not be needed.
Moreover, group membership can only be expressed today as a parameter in individual contexts. However, a group may exist regardless of whether its members are active or not and may persist even when its members actually leave the group. This may cause problems when a group membership is a parameter in an individual context, since the aggregate profile of that group's context is disregarded in an individual context.
It is also sometimes desirable for a group of users to collectively obtain context information, which can be a tedious procedure using the existing solution since its members may have different needs and preferences. In another practical example, a group of users intend to visit a restaurant together and may invoke a telecommunication service providing information on available restaurants and their menus, e.g. based on user locations and preferences. Each user in the group can then invoke such a service and typically receive different results depending on differences in location and preferences. It is then up to the users to coordinate the results and agree on a restaurant that satisfies all users in the group, which naturally may be difficult and time wasting.
To conclude, more flexibility in context servers is desirable when providing context information, and it is also desirable to handle group contexts more efficiently. Further, a useful solution is needed for providing relevant context information on an object of interest to a group requiring a minimum of efforts from its members.